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Abstract 


OpenID has found its usage on the Internet for Web Single Sign-On. 
Simple Authentication and Security Layer (SASL) and the Generic 
Security Service Application Program Interface (GSS-API) are 
application frameworks to generalize authentication. This memo 
specifies a SASL and GSS-API mechanism for OpenID that allows the 
integration of existing OpenID Identity Providers with applications 
using SASL and GSS-API. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6616. 
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Les 


Introduction 


OpenID 2.0 [OpenID] is a web-based three-party protocol that provides 
a means for a user to offer identity assertions and other attributes 
to a web server (Relying Party) via the help of an identity provider. 
The purpose of this system is to provide a way to verify that an end 
user controls an identifier. 


Simple Authentication and Security Layer (SASL) [RFC4422] is used by 
application protocols such as IMAP [RFC3501], Post Office Protocol 
(POP) [RFC1939], and Extensible Messaging and Presence Protocol 
(XMPP) [RFC6120], with the goal of modularizing authentication and 
security layers, so that newer mechanisms can be added as needed. 
This memo specifies just such a mechanism. 


The Generic Security Service Application Program Interface (GSS-APT) 
[RFC2743] provides a framework for applications to support multiple 
authentication mechanisms through a unified interface. This document 
defines a pure SASL mechanism for OpenID, but it conforms to the new 
bridge between SASL and the GSS-API called GS2 [RFC5801]. This means 
that this document defines both a SASL mechanism and a GSS-API 
mechanism. Implementors of the SASL component MAY implement the GSS- 
API interface as well. 


This mechanism specifies interworking between SASL and OpenID in 
order to assert identity and other attributes to Relying Parties. As 
such, while SASL servers (as Relying Parties) will advertise SASL 
mechanisms, clients will select the OpenID mechanism. 


The OpenID mechanism described in this memo aims to reuse the OpenID 
mechanism to the maximum extent and therefore does not establish a 
separate authentication, integrity, and confidentiality mechanism. 

It is anticipated that existing security layers, such as Transport 
Layer Security (TLS) [RFC5246], continue to be used. Minimal changes 
are required to non-web applications, as most of the transaction 
occurs through a normal web browser. Hence, this specification is 
only appropriate for use when such a browser is available. 


Figure 1 describes the interworking between OpenID and SASL. This 
document requires enhancements to the Relying Party and to the Client 
(as the two SASL communication end points), but no changes to the 
OpenID Provider (OP) are necessary. To accomplish this goal, 
indirect messaging required by the OpenID specification is tunneled 
through the SASL/GSS-API mechanism. 
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Figure 1: Interworking Architecture 
1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The reader is assumed to be familiar with the terms used in the 
OpenID 2.0 specification. 


1.2. Applicability 


Because this mechanism transports information that should not be 

controlled by an attacker, the OpenID mechanism MUST only be used 
over channels protected by TLS, and the client MUST successfully 

validate the server certificate [RFC5280] [RFC6125]. 


2. Applicability for Application Protocols other than HTTP 


OpenID was originally envisioned for HTTP- [RFC2616] and HTML-based 
[W3C.REC—-htm1401-19991224] communications, and with the associated 
semantic; the idea being that the user would be redirected by the 
Relying Party (RP) to an identity provider (IdP) who authenticates 
the user and then sends identity information and other attributes 
(either directly or indirectly) to the Relying Party. The identity 
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provider in the OpenID specifications is referred to as an OpenID 
Provider (OP). The actual protocol flow can be found in Section 3 of 
the OpenID 2.0 specification [OpenID]. The reader is strongly 
encouraged to be familiar with that specification before continuing. 


When considering that flow in the context of SASL, we note that while 
the RP and the client both need to change their code to implement 
this SASL mechanism, it is a design constraint that the OP behavior 
remain untouched, in order for implementations to interoperate with 
existing IdPs. Hence, an analog flow that interfaces the three 
parties needs to be created. In the analog, we note that unlike a 
web server, the SASL server already has some sort of session 
(probably a TCP connection) established with the client. However, it 
may be necessary for a SASL client to invoke to another application. 
This will be discussed below. By doing so, we externalize much of 
the authentication from SASL. 


The steps are listed below: 


ci The SASL server advertises support for the SASL OpenID mechanism 
to the client. 


2% The client initiates a SASL authentication and transmits the 
User-Supplied Identifier as its first response. The SASL 
mechanism is client-first, and, as explained in [RFC4422], the 
server will send an empty challenge if needed. 


3% After normalizing the User-Supplied Identifier as discussed in 
[OpenID], the Relying Party performs discovery on it and 
establishes the OP Endpoint URL that the end user uses for 
authentication. 


4. The Relying Party and the OP optionally establish an association 
-- a shared secret established using Diffie-Hellman Key 
Exchange. The OP uses an association to validate those messages 
through the use of a Hashed Message Authentication Code (HMAC); 
this removes the need for subsequent direct requests to verify 
the signature after each authentication request/response. 


5. The Relying Party transmits an authentication request to the OP 
to obtain an assertion in the form of an indirect request. 
These messages are passed through the client rather than 
directly between the RP and the OP. OpenID defines two methods 
for indirect communication -- namely, HTTP redirects and HTML 
form submission. Neither mechanism is directly applicable for 
usage with SASL. To ensure that an OP that is OpenID 2.0 
capable can be used, a new method is defined in this document 
that requires the OpenID message content to be encoded using a 
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Universal Resource Identifier (URI) [RFC3986]. Note that any 
Internationalized Resource Identifiers (IRIs) must be normalized 
to URIs by the SASL client, as specified in [RFC3987], prior to 
transmitting them to the SASL server. 


G. The SASL client now sends a response consisting of "=" to the 
server, to indicate that authentication continues via the normal 
OpenID flow. 


7. At this point, the client application MUST construct a URL 
containing the content received in the previous message from the 
RP. This URL is transmitted to the OP by either the SASL client 
application or an appropriate handler, such as a browser. 


8. Next, the end user optionally authenticates to the OP and then, 
depending on the OP, may approve or disapprove authentication to 
the Relying Party. For reasons of its own, the OP has the 
option of not authenticating a request. The manner in which the 
end user is authenticated to their respective OP and any 
policies surrounding such authentication are out of scope of 
OpenID and, hence, also out of scope for this specification. 
This step happens out of band from SASL. 


SE The OP will convey information about the success or failure of 
the authentication phase back to the RP, again using an indirect 
response via the client browser or handler. The client 
transmits to the RP (over HTTP/TLS) the redirect of the OP 
result. This step happens out of band from SASL. 


10. The RP MAY send an OpenID check_authentication request directly 
to the OP, if no association has been established, and the OP 


should respond. Again, this step happens out of band from SASL. 


11. The SASL server sends an appropriate SASL response to the 
client, with optional Open Simple Registry (SREG) attributes. 
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SASL Serv. RP/Client OP 
| >----- (1) ----- > | | Advertisement 
<----- (2) ----- < | Initiation 
8 N e “<2 = i ------- ,| Discovery 
P SEL EAEN SENE EN E eS R d Association 
Jerse] a Se Eae e < 
|>----- (5)----- ,| | Indirect Auth Request 
Ms TEA (6)----- <| | Client "=" Response 
| the - (7)- - a Client GET to the OP (ext.) 
| <- - (8)- - ->| Client / OP Auth. (ext.) 
le - -(9)- - - ! EES E ao 1 HTTPS Indirect id_res 
p - -(10)- - | ------- ,| Optional 
| | | check_authentication 
| >----- (11) ---->| | SASL completion with status 
~~ = artes 


Note the directionality in SASL is such that the client MUST send the 
"=""response. Specifically, the SASL client processes the redirect 
and then awaits a final SASL decision, while the rest of the OpenID 
authentication process continues. 


2.1. Binding SASL to OpenID in the Relying Party 


OpenID is meant to be used in serial within the web, where browser 
cookies are easily accessible. As such, there are no transaction IDs 
within the protocol. To ensure that a specific request is bound, and 
in particular to ease inter-process communication, the Relying Party 
MUST encode a nonce or transaction ID in the URIs it transmits 
through the client for success or failure, as either a base URI or 
fragment component to the "return_to" URI. This value is to be used 
to uniquely identify each authentication transaction. The nonce 
value MUST be at least 2%32 bits and large enough to handle well in 
excess of the number of concurrent transactions a SASL server shall 
see. 
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2.2. Discussion 


As mentioned above, OpenID is primarily designed to interact with 
web-based applications. Portions of the authentication stream are 
only defined in the crudest sense. That is, when one is prompted to 
approve or disapprove an authentication, anything that one might find 
on a browser is allowed, including JavaScript, complex style-sheets, 
etc. Because of this lack of structure, implementations will need to 
invoke a rich browser in order to ensure that the authentication can 
be completed. 


Once there is an outcome, the SASL server needs to know about it. 

The astute reader will hopefully by now have noticed an "=" client 
SASL response. This is not to say that nothing is happening, but 
rather that authentication flow has shifted from SASL and the client 
application to OpenID within the browser, and it will return to the 
client application when the server has an outcome to hand to the 
client. The alternative to this flow would be some sort of signal 
from the HTML browser to the SASL client of the results that would in 
turn be passed to the SASL server. The inter-process communication 


issue this raises is substantial. Better, we conclude, to 
externalize the authentication to the browser and have an "=" client 
response. 


3. OpenID SASL Mechanism Specification 


This section specifies the details of the OpenID SASL mechanism. 
Recall Section 5 of [RFC4422] for what needs to be described here. 


The name of this mechanism is "OPENID20". The mechanism is capable 
of transferring an authorization identity (via "gs2-header"). The 
mechanism does not offer a security layer. 


The mechanism is client-first. The first mechanism message is from 
the client to the server, and it is the "initial-response" described 
below. As described in [RFC4422], if the application protocol does 
not support sending a client-response together with the 
authentication request, the server will send an empty server- 
challenge to let the client begin. 


The second mechanism message is from the server to the client, and it 
is the "authentication_request" described below. 


The third mechanism message is from client to the server, and it is 
the fixed message consisting of "=". 
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The fourth mechanism message is from the server to the client, 
described below as "outcome_data" (with SREG attributes), sent as 
additional data when indicating a successful outcome. 


3.1. Initiation 


A client initiates an OpenID authentication with SASL by sending the 
GS2 header followed by the URI, as specified in the OpenID 
specification. 


The ABNF [RFC5234] syntax is as follows: 


initial-response = gs2-header Auth-Identifier 
Auth-Identifier = Identifier ; authentication identifier 
Identifier = URI ; Identifier is specified in 

; Sec. 7.2 of the OpenID 2.0 spec. 


The syntax and semantics of the "gs2-header" are specified in 
[RFC5801], and we use it here with the following limitations: The 
"gs2-nonstd-flag" MUST NOT be present. The "gs2-cbh-flag" MUST be "n" 
because channel binding is not supported by this mechanism. 


URI is specified in [RFC3986]. Extensible Resource Identifiers 
(XRIs) [XRI2.0] MUST NOT be used. 


3.2. Authentication Request 


The SASL server sends the URL resulting from the OpenID 
authentication request, containing an "openid.mode" of either 
"checkid_immediate" or "checkid_setup", as specified in Section 9.1 
of the OpenID 2.0 specification [OpenID]. 


authentication-request = URI 


As part of this request, the SASL server MUST append a unique 
transaction ID to the "return_to" portion of the request. The form 
of this transaction is left to the RP to decide, but it SHOULD be 
large enough to be resistant to being guessed or attacked. 


The client now sends that request via an HTTP GET to the OP, as if 
redirected to do so from an HTTP server. 


The client MUST handle both user authentication to the OP and 


confirmation or rejection of the authentication by the RP via this 
SASL mechanism. 
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After all authentication has been completed by the OP, and after the 
response has been sent to the client, the client will relay the 
response to the Relying Party via HTTP/TLS, as specified previously 
in the transaction ("return_to"). 


3.3. Server Response 


The Relying Party now validates the response it received from the 
client via HTTP/TLS, as specified in the OpenID specification, using 
the "return_to" URI given previously in the transaction. 


The response by the Relying Party constitutes a SASL mechanism 
outcome, and it SHALL be used to set state in the server accordingly. 
Also, it SHALL be used by the server to report that state to the SASL 
client as described in Section 3.6 of [RFC4422]. In the additional 
data, the server MAY include OpenID Simple Registry (SREG) attributes 
that are listed in Section 4 of [SREG1.0]. SREG attributes are 
encoded as follows: 


1. Strip "openid.sreg." from each attribute name. 

2. Treat the concatenation of results as URI parameters that are 
separated by an ampersand (&) and encode as one would a URI, 
absent the scheme, authority, and the question mark. 


For example: email=lear@example.com&fullname=Eliot%20Lear 


More formally: 


outcome-data = [ sreg-avp *( "," sreg-avp ) ] 
sreg-avp = sreg-attr "=" sreg-val 
sreg-attr = sreg-word 

sreg-val = sreg-word 

sreg-word = 1*( unreserved / pct-encoded ) 


; pct-encoded from Section 2.1 of RFC 3986 
; unreserved from Section 2.3 of RFC 3986 


A client who does not support SREG MUST ignore SREG attributes sent 
by the server. Similarly, a client MUST ignore unknown attributes. 


In the case of failures, the response MUST follow this syntax: 


outcome-data = "openid.error" "=" sreg-val *( "," sregp-avp ) 
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3.4. Error Handling 


Section 3.6 of [RFC4422] explicitly prohibits additional information 
in an unsuccessful authentication outcome. Therefore, the 
openid.error and openid.error_code are to be sent as an additional 
challenge in the event of an unsuccessful outcome. In this case, as 
the protocol is in lockstep, the client will follow with an 
additional exchange containing "=", after which the server will 
respond with an application-level outcome. 


4. OpenID GSS-API Mechanism Specification 


This section MUST be observed to properly implement the GSS-API 
mechanism that is described below. 


The OpenID SASL mechanism is actually also a GSS-API mechanism. The 
OpenID user takes the role of the GSS-API Initiator and the OpenID 
Relying Party takes the role of the GSS-API Acceptor. The OpenID 
Provider does not have a role in GSS-API and is considered an 
internal matter for the OpenID mechanism. The messages are the same, 
but a) the GS2 header on the client’s first message and channel 
binding data are excluded when OpenID is used as a GSS-API mechanism, 
and b) the initial context token header (described in Section 3.1 of 
RFC 2743) is prefixed to the client’s first authentication message 
(context token). 


The GSS-API OID for the OpenID 2.0 mechanism is 1.3.6.1.5.5.16 (see 
Section 7 for more information). The DER encoding of the OID is 0x2b 
0x06 0x01 0x05 0x05 0x10. 


OpenID security contexts MUST have the mutual_state flag 
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 
delegation; therefore, OpenID security contexts MUST have the 
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 


The mutual authentication property of this mechanism relies on 
successfully comparing the TLS server identity with the negotiated 
target name. Since the TLS channel is managed by the application 
outside of the GSS-API mechanism, the mechanism itself is unable to 
confirm the name while the application is able to perform this 
comparison for the mechanism. For this reason, applications MUST 
match the TLS server identity with the target name, as discussed in 
[RFC6125]. 


The OpenID mechanism does not support per-message tokens or 
GSS_Pseudo_random. 
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The [RFC5587] mechanism attributes for this mechanism are 
GSS_C_MA_ MECH _CONCRETE, GSS_C_MA ITOK_FRAMED, and GSS_C_MA AUTH_INIT. 

4.1. GSS-API Principal Name Types for OpenID 


OpenID supports standard generic name syntaxes for acceptors such as 
GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]). 


OpenID supports only a single name type for initiators: 
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 
OpenID. 


OpenID name normalization is covered by the OpenID specification; see 
Section 7.2 of [OpenID]. 


The query, display, and exported name syntaxes for OpenID principal 
names are all the same. There are no OpenID-specific name syntaxes 
-—- applications should use generic GSS-API name types such as 
GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see Section 4 of 
[RFC2743]). The exported name token does, of course, conform to 
Section 3.2 of [RFC2743], but the "NAME" part of the token should be 
treated as a potential input string to the OpenID name normalization 
rules. For example, the OpenID Identifier "https://openid.example/" 
will have a GSS_C_NT_USER_NAME value of "https://openid.example/". 


GSS-API name attributes may be defined in the future to hold the 
normalized OpenID Identifier. 


5. Example 


Suppose a user has an OpenID of https://openid.example and wishes to 
authenticate his IMAP connection to mail.example (where .example is 
the top-level domain specified in [RFC2606]). The user would input 
his OpenID into his mail user agent when he configures the account. 
In this case, no association is attempted between the OpenID RP and 
the OP. The client will make use of the "return_to" attribute to 
capture results of the authentication to be redirected to the server. 
Note the use of [RFC4959] for the initial response. The 
authentication on the wire would then look something like the 
following: 
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(S = IMAP server; C = IMAP client) 


< connects to IMAP port> 

* OK 

C1 CAPABILITY 

* CAPABILITY IMAP4revl SASL-IR SORT [...] AUTH=OPENID20 


Cl OK Capability Completed 

C2 AUTHENTICATE OPENID biwsaHROcHM6Ly 9vcGVuaWQuZXhhbXBsZS 8= 
This is the base64 encoding of "n,,https://openid.example/". 
Server performs discovery on http://openid.example/ ] 

S: + aHROcHM6Ly9vcGVuaWOuZXhhbxXBsZS 9vcGVuaWOvP 2 9wZW5pZC5ucz1 
odHRw0i8vc3B1Y3Mub3Blbm1kLm51dC9hdXRoLzIuMCZvcGVuawQucm 
VOdXJuX3RVvPWhOdHBz0i 8vbWFpbC51leGFtcGx1lL2NvbnN1bWVyLzF1Z 
jg40GMmb3Blbm1kLmNsYW1t ZWRfaWQ9aHROCHM6LYyIVcGVuaWQuZxXhh 
bXBsZS8mb3Blbm1kLm1kZW50aXRSPWhOdHBz0i 8vb3Blbm1kLmv4YW1 
woGUvJUm9wZW5pZC5yZWE sbT1pbWEwOi 8vbWFpbC51leGFtcGxlJm9wZw 
5pZC5tb2R1PWNoZWNraWRfc2V0dxA= 


TA“ANNAMNA|A 


[ This is the base64 encoding of "https://openid.example/openid/ 
?openid.ns=http://specs.openid.net/auth/2.0 
é&éopenid.return_to=https://mail.example/consumer/lef888c 
&openid.claimed_id=https://openid.example/ 
&openid.identity=https://openid.example/ 
é&0penid.realm=imap://mail.example 
é&0penid.mode=checkid_setup" 

with line breaks and spaces added here for readability. 


=a 
U 
O 
Il 
ll 


The client now sends the URL it received to a browser for 
processing. The user logs into https://openid.example and 
agrees to authenticate imap://mail.example. A redirect is 
passed back to the client browser that then connects to 
https://imap.example/consumer via SSL with the results. 

From an IMAP perspective, however, the client sends the "=" 
response, and awaits mail.example. 

Server mail.example would now contact openid.example with an 
openid.check_authentication message. After that... 


vN — 


+ ZWlhaWw9bGVhckBt YW1lsLmV4YW1lwbGUsZnVsbG5ShbWU IRWxp 
b3Q1MjBMZWEFy 

[ Here, the IMAP server has returned an SREG attribute of 
email=lear@mail.example, fullname=Eliot%20Lear. 
Line break in response added in this example for readability. ] 


[ In IMAP, client must send a blank response after receiving 
the SREG data. ] 
S: C2 OK 


Lear, et al. Standards Track [Page 13] 


RFC 6616 SASL & GSS-API Mechanism for OpenID May 2012 


In this example, the SASL server / RP has made use of a transaction 
ID lef888c. 


6. Security Considerations 


This section will address only security considerations associated 
with the use of OpenID with SASL and GSS-API. For considerations 
relating to OpenID in general, the reader is referred to the OpenID 
specification [OpenID] and to other literature [OpReview]. 
Similarly, for general SASL [RFC4422] and GSS-API [RFC5801] security 
considerations, the reader is referred to those specifications. 


6.1. Binding OpenIDs to Authorization Identities 


As specified in [RFC4422], the server is responsible for binding 
credentials to a specific authorization identity. It is therefore 
necessary that a registration process takes place in advance that 
binds specific OpenIDs to specific authorization identities, or that 
only specific trusted OpenID Providers be allowed, where a mapping is 
predefined. For example, it could be prearranged between an IdP and 
RP that "https://example.com/user" maps to "user" for purposes of 
authorization. 


6.2. RP Redirected by Malicious URL to Take an Improper Action 


In the initial SASL client response, a user or host can transmit a 
malicious response to the RP for purposes of taking advantage of 
weaknesses in the RP’s OpenID implementation. It is possible to add 
port numbers to the URL so that the outcome is that the RP does a 
port scan of the site. The URL could contain an unauthorized host or 
even the local host. The URL could contain a protocol other than 
http or https, such as file or ftp. 


One mitigation would be for RPs to have a list of authorized URI 
bases. OPs SHOULD only redirect to RPs with the same domain 
component of the base URI. RPs MUST NOT automatically retry on 
failed attempts. A log of those sites that fail SHOULD be kept, and 
limitations on queries from clients SHOULD be imposed, just as with 
any other authentication attempt. Applications SHOULD NOT invoke 
browsers to communicate with OPs that they are not themselves 
configured with. 


6.3. User Privacy 
The OP is aware of each RP that a user logs into. There is nothing 
in the protocol to hide this information from the OP. It is nota 


requirement to track the visits, but there is nothing that prohibits 
the collection of information. SASL servers should be aware that 
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Oi. 


9. 


OpenID Providers will be able to track -- to some extent -- user 
access to their services and any additional information that OP 
provides. 


IANA Considerations 


IANA has updated the "SASL Mechanisms" registry using the following 
template, as described in [RFC4422]. 


SASL mechanism name: OPENID20 
Security Considerations: See this document 
Published specification: See this document 


Person & email address to contact for further information: Authors of 
this document 


Intended usage: COMMON 

Owner/Change controller: IESG 
Note: None 

IANA has also assigned an OID for this GSS mechanism in the "SMI 
Security for Mechanism Codes" registry, with the prefix of 
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and 
referencing this specification in the registry. 
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